The present invention generally relates to automatic generation of software code and data files and, more particularly, to automated generation of telemetry software for use by flying vehicles, such as spacecraft, along with automated generation of a number of types of auxiliary data files for use with telemetry software.
Flying vehicles such as aircraft, spacecraft, and missiles often rely on embedded flight software for telemetry of flight information and control data to a ground control and monitoring center. An image familiar to most people is that of a NASA (National Aeronautics and Space Administration) or JPL (Jet Propulsion Laboratory) mission control room where perhaps dozens of engineers sit at computer consoles to monitor and control the flight of spacecraft. One of the tasks of such embedded flight software is to generate a telemetry stream of internal data from the vehicle. Such data may include, for example, position data (e.g., latitude, longitude, altitude), velocity, and orientation of the vehicle. When the vehicle is airborne, the flight software is required to generate this telemetry stream and radio it down to the ground where the data in it is unpacked and displayed in real-time.
The flight software and software required for unpacking and displaying telemetry data, i.e., decoding software, may vary from vehicle to vehicle and may even vary from mission to mission for the same vehicle and thus may need to be configured according to each project, i.e., vehicle and mission. The job of producing software for each project may be characterized by three major components: (1) defining the format of the telemetry stream in some readable format (e.g. an Excel file, or Word document); (2) writing the real-time embedded flight software that will gather up the necessary internal flight software variables and format them according to the defined format; and (3) writing the necessary decoding software that will reside in ground-based computers that will decode the telemetry stream according to the defined format.
Each of these three major job components is typically labor-intensive, error-prone, and time consuming. For example, there are usually hundreds of parameters to be telemetered, with each parameter having a number of attributes which must be captured (e.g., rate of telemetry, location in telemetry stream, number of bits occupied, how value is represented in the telemetry stream, any scaling of the parameter, description) yielding a large number of pieces of information that must be determined and entered appropriately. Processing the “information volume” alone can consume a large portion of project labor hours and schedule. In addition, both the flight software and the ground-based decoding software usually must be implemented, with the exact same values of these thousands of telemetry parameter attributes, by multiple engineers working in different groups. Some of the telemetry parameter attributes are forced to be entered into the flight software multiple times in slightly different representations—representations that may not be engineer-friendly, but are necessary to generate the flight software. The contingency that a particular piece of information may not be entered consistently in all places creates a possible source of error.
Thus, the telemetry flight software normally is, of necessity, voluminous and complex so that verification of its correctness, e.g., that the actual telemetry stream matches the definition of the format of the telemetry stream, can be difficult for telemetry flight software developers. The resulting flight software, in which the telemetry flight software may be embedded, is usually so large and complex that it may be difficult for fellow flight-software developers to adequately review the implementation of the telemetry flight software to help positively verify its correctness. For example, It is usually difficult to notice when one of the above described parameter attribute values is either determined or entered erroneously. Yet, it can be similarly time-consuming and error-prone to construct software tests to prove the correctness of the flight software. In the same vein, it is usually difficult to verify the correctness of the ground-based decoding software. Another difficulty that frequently arises is that all projects generally are forced to add to and change their telemetry streams multiple times as a project progresses, causing multiple iterations of many of the above challenges to be faced.
As can be seen, there is a need for providing telemetry flight software that is verifiable and providing such software along with reliable specifications for defining the format of the telemetry stream. There is also a need for providing decoding software and verification.